Operating systems provide applications access to graphics hardware for video processing using specified application programming interfaces (APIs). Certain CPU-intensive operations, such as inverse discrete cosine transform, motion compensation, de-interlacing, color correction, video capturing and video processing operations may be performed using the graphics hardware to be accelerated. This video acceleration works in conjunction with a video rendering model used by the graphics hardware (video card).
However, some video acceleration systems provide only limited support for High-Definition video, such as Blu-ray, HD DVD and ISDB-T. Some of the limitations include support for only a single stream of video, support for either multiple YCbCr streams or a single RGB stream, interlacing and de-interlacing of only the main video stream, unsupported composition primitives, limited background support, and others. The limitations make it difficult to provide, for example, a High-Definition video player because of inefficiencies in the 3D graphics pipeline. As such, YCbCr streams and RGB streams cannot be composed in a single pass, and the sub video stream requires a pre-processing stage for de-interlacing. In addition, the streams cannot be different frame rates, and the output frame rate is assumed the same as the input frame rate that is not applicable to telecined film source.
Due to the limitations and the missing functionalities, software vendors and hardware vendors are bypassing the APIs and using specifically designed private interfaces and graphics hardware. Software vendors are using a D3D shader for video processing and composition, which is inefficient and does not support low-end graphics hardware and mobile systems. Hardware vendors are shipping video cards with dedicated video processing hardware. Often the vendors encounter difficulties because of the specifics of their hardware and/or software implementations.